keep/providers/cloudwatch_provider/alerts_mock.py (1)

14-14: Consider namespace consistency with pod-related alerts.

The new alarm names are more descriptive and better reflect real-world scenarios. However, "PodRecycled" seems inconsistent with the AWS/EC2 namespace in the alert payload. If these alerts are meant to simulate Kubernetes pod scenarios, consider using a more appropriate namespace (e.g., ContainerInsights).

Consider this modification:

-            "Message.AlarmName": ["HighCPUUsage", "HighCPUUsageOnAPod", "PodRecycled"],
+            "Message.AlarmName": ["HighCPUUsage", "HighCPUUsageOnInstance", "InstanceRecycled"],

Or update the namespace if these are meant to be Kubernetes-related alerts:

             "MetricName": "CPUUtilization",
-            "Namespace": "AWS/EC2",
+            "Namespace": "ContainerInsights",

scripts/simulate_alerts.py (1)

Line range hint 1-31: Well-structured refactoring of alert simulation

The changes effectively:

• Simplify the script by moving complex logic to a dedicated module
• Provide configuration flexibility through environment variables
• Follow separation of concerns principle

This aligns well with the PR objective of implementing demo mode.

keep/providers/datadog_provider/alerts_mock.py (1)

Line range hint 1-38: Consider documenting the alert variation logic

Since this mock data will be used by the new demo mode feature, it would be helpful to add comments explaining:

1. The purpose of parameter variations
2. How the demo mode selects between different parameter options
3. The relationship between payload defaults and parameter variations

This documentation would help maintainers understand the demo mode behavior.

keep/providers/prometheus_provider/alerts_mock.py (2)

23-23: Consider making customer_id configurable for demo flexibility

While "acme" is a good default, consider making the customer_id a parameter for more flexible demos. This would allow demonstrating multi-tenant scenarios more effectively.

"parameters": {
    "labels.queue": ["queue1", "queue2", "queue3"],
    "labels.service": ["calendar-producer-java-otel-api-dd", "kafka", "queue"],
    "labels.mq_manager": ["mq_manager1", "mq_manager2", "mq_manager3"],
+   "labels.customer_id": ["acme", "demo-corp", "test-org"],
},

Also applies to: 28-28

---

14-14: Consider reducing service list duplication

The same service list appears in multiple alerts. Consider defining it once as a constant to improve maintainability.

+COMMON_SERVICES = ["calendar-producer-java-otel-api-dd", "kafka", "api", "queue", "db"]

 ALERTS = {
     "high_cpu_usage": {
         # ...
         "parameters": {
-            "labels.service": ["calendar-producer-java-otel-api-dd", "kafka", "api", "queue", "db"],
+            "labels.service": COMMON_SERVICES,

Also applies to: 41-41, 54-54

keep/api/config.py (1)

62-73: Ensure idempotency of when_ready function.

The function should be idempotent as it might be called multiple times by the server. Consider adding a guard to prevent multiple initializations of demo mode.

+_demo_mode_initialized = False

 def when_ready(server):
     """This function is called by the gunicorn server when it is ready to accept requests"""
     logger.info("Keep server ready")

     launch_uptime_reporting()

-    if LIVE_DEMO_MODE:
+    global _demo_mode_initialized
+    if LIVE_DEMO_MODE and not _demo_mode_initialized:
         logger.info("Launching Keep in demo mode.")
         try:
             from keep.api.core.demo_mode_runner import launch_demo_mode
             launch_demo_mode()
+            _demo_mode_initialized = True
         except Exception as e:
             logger.error(f"Failed to launch demo mode: {e}")
     else:
         logger.info("Not launching Keep in demo mode.")

keep/providers/grafana_provider/alerts_mock.py (1)

Line range hint 4-97: Consider establishing service categorization standards

The addition of service categorization is a good enhancement, but there seems to be no clear standard for service naming. Consider:

1. Documenting the allowed service categories
2. Establishing naming conventions for services
3. Adding validation for service values

This would be particularly important for the demo mode feature to ensure consistent and realistic alert simulation.

keep/api/core/demo_mode_runner.py (3)

394-394: Fix the typo in the docstring.

There's a typo in the docstring: "backgound" should be "background".

Apply this diff to correct the typo:

     """
-    Running async demo in the backgound.
+    Running async demo in the background.
     """

---

399-400: Ensure the default port is correctly set as a string.

When constructing keep_api_url, ensure that the default port is a string to avoid issues during string concatenation.

Apply this diff to set the default port as a string:

 keep_api_url = os.environ.get(
-    "KEEP_API_URL", "http://localhost:" + str(os.environ.get("PORT", 8080))
+    "KEEP_API_URL", "http://localhost:" + os.environ.get("PORT", "8080")
 )

---

338-390: Add a top-level exception handler in the simulate_alerts loop.

To prevent the simulate_alerts thread from exiting unexpectedly due to unhandled exceptions, consider adding a top-level exception handler around the while True loop. This ensures that any unforeseen errors are logged and the loop continues running.

Apply this diff to add a top-level exception handler:

 def simulate_alerts(
     keep_api_url=None,
     keep_api_key=None,
     sleep_interval=5,
     demo_correlation_rules=False,
     demo_topology=False,
 ):
     logger.info("Simulating alerts...")
     GENERATE_DEDUPLICATIONS = True

     providers = [
         "prometheus",
         "grafana",
         "cloudwatch",
         "datadog",
     ]

     providers_to_randomize_fingerprint_for = [
         "cloudwatch",
         "datadog",
     ]

     provider_classes = {
         provider: ProvidersFactory.get_provider_class(provider)
         for provider in providers
     }

     if demo_correlation_rules:
         logger.info("Creating correlation rules...")
         get_or_create_correlation_rules(keep_api_key, keep_api_url)
         logger.info("Correlation rules created.")
     if demo_topology:
         logger.info("Creating topology...")
         get_or_create_topology(keep_api_key, keep_api_url)
         logger.info("Topology created.")

+    try:
         while True:
             logger.info("Looping to send alerts...")

             logger.info("Removing old incidents...")
             remove_old_incidents(keep_api_key, keep_api_url)
             logger.info("Old incidents removed.")

             # choose provider
             provider_type = random.choice(providers)
             send_alert_url = "{}/alerts/event/{}".format(keep_api_url, provider_type)
             provider = provider_classes[provider_type]
             alert = provider.simulate_alert()

             send_alert_url_params = {}

             if provider_type in providers_to_randomize_fingerprint_for:
                 send_alert_url_params["fingerprint"] = "".join(
                     random.choices("abcdefghijklmnopqrstuvwxyz0123456789", k=10)
                 )

             # Determine number of times to send the same alert
             num_iterations = 1
             if GENERATE_DEDUPLICATIONS:
                 num_iterations = random.randint(1, 3)

             for _ in range(num_iterations):
                 logger.info("Sending alert: {}".format(alert))
                 try:
                     env = random.choice(["production", "staging", "development"])
                     send_alert_url_params["provider_id"] = f"{provider_type}-{env}"
                     prepared_request = PreparedRequest()
                     prepared_request.prepare_url(send_alert_url, send_alert_url_params)
                     response = requests.post(
                         prepared_request.url,
                         headers={"x-api-key": keep_api_key},
                         json=alert,
                     )
                     response.raise_for_status()  # Raise an HTTPError for bad responses
                 except requests.exceptions.RequestException as e:
                     logger.error("Failed to send alert: {}".format(e))
                     time.sleep(sleep_interval)
                     continue

                 if not response.ok:
                     logger.error("Failed to send alert: {}".format(response.text))
                 else:
                     logger.info("Alert sent successfully")

             logger.info(
                 "Sleeping for {} seconds before next iteration".format(sleep_interval)
             )
             time.sleep(sleep_interval)
+    except Exception as e:
+        logger.exception("An unexpected error occurred in simulate_alerts: {}".format(e))

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Check the implementation of simulate_alerts to understand correlation rules
ast-grep --pattern 'def simulate_alerts($$$)' 

# Search for any correlation rules implementation
rg 'correlation.*rules|rules.*correlation' -A 5

#!/bin/bash
# Search for any existing sleep intervals in alert-related files for comparison
rg -g '!*.pyc' -g '!*.git' 'sleep.*interval|interval.*sleep' 

#!/bin/bash
# Check the alert simulation logic and timing patterns
rg "time\.sleep|SLEEP_INTERVAL" -B 2 -A 2

#!/bin/bash
# Description: Check uptime reporting behavior in demo mode

# Look for uptime reporting configuration and usage
rg -A 5 "launch_uptime_reporting"

# Check if demo mode affects uptime reporting
ast-grep --pattern 'launch_uptime_reporting($$$)'

#!/bin/bash
# Check uptime reporting implementation and demo mode configuration
rg -A 10 "POSTHOG_DISABLED|LIVE_DEMO_MODE" keep/api/core/

# Check if there's any interaction between demo mode and uptime reporting
rg -A 5 "is_posthog_reachable|report_uptime" keep/api/core/demo_mode_runner.py

#!/bin/bash
# Check for consistency in service categorization across memory-related alerts
rg -A 5 'memory.*service' --type py

#!/bin/bash
# Search for alert definitions containing "memory" in grafana provider
rg -B 5 -A 10 '"memory"' keep/providers/grafana_provider/

#!/bin/bash
# Search for service field in alert definitions
rg -B 5 -A 10 '"service":' keep/providers/grafana_provider/

#!/bin/bash
# Get the full content of alerts_mock.py to understand the context
cat keep/providers/grafana_provider/alerts_mock.py

keep/api/core/demo_mode_runner.py (1)

25-55: Consider moving correlation rules to a configuration file.

While the rules are well-structured, having them hardcoded in the source code makes it less maintainable. Consider moving them to a separate configuration file (e.g., YAML or JSON) for easier maintenance and updates.

Configuration used: CodeRabbit UI
Review profile: CHILL

keep/api/core/demo_mode_runner.py (2)

302-308: Add rate limiting for alert generation.

The alert simulation lacks rate limiting which could overwhelm the API endpoints.

Consider implementing a token bucket rate limiter:

+from keep.api.utils.rate_limiter import TokenBucketRateLimiter
+
 def simulate_alerts(
     keep_api_url=None,
     keep_api_key=None,
     sleep_interval=5,
     demo_correlation_rules=False,
-    demo_topology=False,
+    demo_topology=False,
+    requests_per_minute=60,
 ):
+    rate_limiter = TokenBucketRateLimiter(requests_per_minute)

---

335-336: Fix static analysis issues.

Two minor issues found:

1. Unused exception variable
2. Unnecessary f-string

Apply these fixes:

-        except requests.exceptions.RequestException as e:
+        except requests.exceptions.RequestException:
-            logger.info(f"Demo thread: API is not up yet. Waiting...")
+            logger.info("Demo thread: API is not up yet. Waiting...")

🧰 Tools

🪛 Ruff

335-335: Local variable e is assigned to but never used

Remove assignment to unused variable e

(F841)

---

336-336: f-string without any placeholders

Remove extraneous f prefix

(F541)

Configuration used: CodeRabbit UI
Review profile: CHILL

+    shutdown_flag = threading.Event()
-    while True:
+    while not shutdown_flag.is_set():
         try:
             logger.info("Looping to send alerts...")

+    sleep_interval = float(os.environ.get("KEEP_DEMO_SLEEP_INTERVAL", "5.0"))
     thread = threading.Thread(
         target=simulate_alerts,
         kwargs={
             "keep_api_key": keep_api_key,
             "keep_api_url": keep_api_url,
-            "sleep_interval": 0.2,
+            "sleep_interval": sleep_interval,
             "demo_correlation_rules": True,
         },
     )
-    thread.daemon = True
+    # Register thread for cleanup on application shutdown
+    from keep.api.utils.thread_manager import register_cleanup_thread
+    register_cleanup_thread(thread)

keep/api/core/demo_mode_runner.py (1)

302-405: Improve alert simulation robustness and configurability.

The alert simulation could be enhanced in several ways:

1. Alert payload validation before sending
2. Configurable alert types and severity levels
3. Metrics collection for monitoring the demo mode

Consider adding alert validation and metrics:

+from prometheus_client import Counter, Histogram
+
+alerts_sent = Counter('demo_alerts_sent_total', 'Number of demo alerts sent', ['provider', 'status'])
+alert_duration = Histogram('demo_alert_duration_seconds', 'Time taken to send demo alerts')
+
 def simulate_alerts(...):
     while True:
         try:
             provider_type = random.choice(providers)
             alert = provider.simulate_alert()
+            
+            # Validate alert payload
+            if not provider.validate_alert(alert):
+                logger.error(f"Invalid alert payload for {provider_type}")
+                continue
+            
+            with alert_duration.time():
                 response = requests.post(...)
+                alerts_sent.labels(provider=provider_type, status='success').inc()
         except Exception as e:
+            alerts_sent.labels(provider=provider_type, status='error').inc()
             logger.exception("Error in simulate_alerts")

Configuration used: CodeRabbit UI
Review profile: CHILL

Configuration used: CodeRabbit UI
Review profile: CHILL

+    shutdown_flag = threading.Event()
-    while True:
+    while not shutdown_flag.is_set():
         try:
             logger.info("Looping to send alerts...")

keep/api/core/demo_mode_runner.py (2)

25-55: Consider adding type hints and documentation for correlation rules.

The correlation rules configuration would benefit from:

1. Type hints using a Pydantic model or dataclass
2. Documentation explaining the rule format and parameters

+from typing import List, Dict, Union
+from dataclasses import dataclass
+
+@dataclass
+class CorrelationRule:
+    """Defines a rule for correlating alerts based on SQL and CEL queries.
+    
+    Attributes:
+        sqlQuery: SQL query configuration for matching alerts
+        groupDescription: Description of the alert group
+        ruleName: Unique name of the rule
+        celQuery: CEL query for matching alerts
+        timeframeInSeconds: Time window for grouping alerts
+        timeUnit: Unit of time for the timeframe
+        groupingCriteria: Criteria for grouping alerts
+        requireApprove: Whether approval is required
+        resolveOn: When to resolve the alert group
+    """
+    sqlQuery: Dict[str, Union[str, Dict[str, str]]]
+    groupDescription: str
+    ruleName: str
+    celQuery: str
+    timeframeInSeconds: int
+    timeUnit: str
+    groupingCriteria: List[str]
+    requireApprove: bool
+    resolveOn: str
+
+correlation_rules_to_create: List[CorrelationRule] = [
     {
         "sqlQuery": {"sql": "((name like :name_1))", "params": {"name_1": "%mq%"}},

---

1-450: Consider architectural improvements for better maintainability.

The current implementation could benefit from:

1. Separation of concerns: Move configuration to separate files
2. Dependency injection: Extract HTTP client and make it injectable
3. Better testability: Extract core logic from I/O operations
4. Monitoring: Add metrics for alert simulation health

Consider:

1. Creating separate configuration modules for rules, topology, and applications
2. Implementing an abstract HTTP client interface
3. Adding health checks and metrics endpoints
4. Implementing proper logging and monitoring

Would you like me to provide a detailed architectural proposal?

Configuration used: CodeRabbit UI
Review profile: CHILL

keep/api/core/demo_mode_runner.py (1)

1-23: Consider organizing imports and adding type hints.

The imports could be better organized by grouping them into:

1. Standard library imports
2. Third-party imports
3. Local imports

Also, consider adding type hints to improve code maintainability.

 import datetime
 import logging
 import os
 import random
 import threading
 import time
-from datetime import timezone
+from datetime import timezone
+from typing import Dict, List, Optional
 
 import requests
 from dateutil import parser
 from requests.models import PreparedRequest

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for any dependencies between uptime reporting and demo mode

# Check if demo mode affects or depends on uptime reporting
rg -A 5 "launch_uptime_reporting|launch_demo_mode" --type py

# Check for any shared resources or configurations
ast-grep --pattern 'def launch_$_() {
  $$$
}'

#!/bin/bash
# Check the implementation details of both launch functions
cat keep/api/core/report_uptime.py
cat keep/api/core/demo_mode_runner.py

# Check if there are any shared dependencies or configurations
rg "POSTHOG_DISABLED|is_posthog_reachable" --type py

     if LIVE_DEMO_MODE:
         logger.info("Launching Keep in demo mode.")
-        from keep.api.core.demo_mode_runner import launch_demo_mode
-        launch_demo_mode()
+        try:
+            from keep.api.core.demo_mode_runner import launch_demo_mode
+            launch_demo_mode()
+        except ImportError as e:
+            logger.error(f"Failed to import demo mode module: {e}")
+            raise
+        except Exception as e:
+            logger.error(f"Failed to launch demo mode: {e}")
+            # Consider whether to continue or exit based on your requirements
+            raise